Внедрение сервисной шины предприятия (ESB, сокр. от англ. enterprise service bus) — непростая задача даже для интеграторов, которые развёртывали десятки похожих решений. Нужно определить, какая архитектура подойдёт в конкретном проекте, найти эффективный способ передачи данных, понять, как лучше реализовать сервисы внутри шины.
В 2022 году команда KT.Team на собственном опыте убедилась: если не следовать процессам и не задавать себе и заказчику правильные вопросы на этапе аналитики, даже понятные интеграции можно сделать неправильно. Мы быстро запустили первую версию шины для стартапа, а затем дважды её переделывали. Рассказываем, почему так случилось, чему мы научились и как не повторять наши ошибки.
Немного контекста
В прошлом году KT.Team внедрила сервисную шину для стартапа «АТИМО», который создал приложение для автоматического получения путевых листов для водителей.
«АТИМО» работает с таксопарками и автопарками, которые не хотят держать в штате механика и медика. Такие компании пользуются автоматизированными пунктами проверки технического состояния машин и здоровья водителей. В этих пунктах технический специалист и врач проводят осмотры и загружают результаты в систему «АТИМО» для обработки. Таксопарк отправляет в «АТИМО» информацию о водителях и машинах, а в ответ получает готовый путевой лист в приложении.
Пока таксопарков было только два, каждый из них подключался к системе напрямую, но будущее масштабирование заставило «АТИМО» задуматься об изменении архитектуры своего IT-решения.
На этом этапе «АТИМО» обратились в KT.Team. Им требовалась сервисная шина — программное обеспечение, которое гибко интегрирует разные системы. Шина должна была взять на себя обмен данными между таксопарком, пунктами технического и медицинского осмотра и базами «АТИМО», не перегружая сервер.
Первая ошибка: построить архитектуру шины по аналогии с прямой интеграцией
Что сделали
Архитектуру шины выстроили по аналогии с прямым подключением: создали сервис, который каждые 20 минут запрашивал данные у каждой базы по очереди.
У такой архитектуры был большой плюс — она требовала почти в 10 раз меньше ресурсов сервера. Если при прямом подключении каждый запрос «съедал» до 4 Гб памяти, то в версии ESB 1.0 на один запрос уходило около 500 Мб.
В чём ошибка
На старте внедрения к шине нужно было подключить только два таксопарка, поэтому команда KT.Team решила пойти по достаточно простому пути. ESB 1.0 проработала полгода, в течение которых к системе «АТИМО» начали подключать новые таксопарки. Когда их количество выросло до 10, стало понятно, что шина абсолютно не устойчива к отказу.
Причиной проблем была изначально неверная архитектура шины: чем больше баз к ней подключено, тем выше риск сбоя. Опрос баз данных проходил последовательно, и если одна не отвечала или обрывала соединение, шина переставала работать, т. е. если сбой произошёл при подключении к самому первому таксопарку, все остальные таксопарки тоже оставались без путевых листов.
Кроме того, для передачи информации в ESB 1.0 использовался брокер сообщений. Шина пересылала данные от таксопарка в систему «АТИМО» и обратно как есть, никак их не обрабатывая. Обмен был не всегда корректным, часть сообщения могла потеряться.
Как надо было сделать
Использование отдельных сервисов для каждого подключения сделает архитектуру менее связанной: сбой одной базы не повлияет на обмен данными с другими. Такая архитектура будет более отказоустойчивой.
Чтобы передача данных стала более стабильной, лучше использовать внутреннее хранилище — собственные базы данных шины. Шина будет получать данные от баз таксопарков и «АТИМО» и сохранять их у себя. Так передача будет работать быстрее и стабильнее.
Вторая ошибка: бороться с симптомами, а не решать главную проблему
Что сделали
Команда KT.Team планировала использовать в ESB 2.0 несколько сервисов для сбора данных вместо одного и две внутренние базы данных вместо брокера сообщений.
В итоге реализовали промежуточное решение: оставили один сервис для всех таксопарков, но полностью поменяли логику обмена данными. Брокер сообщений заменили на базы данных: одна — для информации о машинах и водителях, другая — для готовых путевых листов. И уже из этих баз шина передавала данные по запросу в систему «АТИМО» или таксопарку.
Такое решение приняли по двум причинам. Во-первых, новая версия шины требовала больше ресурсов, ведь все таксопарки нужно обрабатывать одновременно, а не по очереди. Во-вторых, приоритетом заказчика было быстрое внедрение изменений, а на полную переработку архитектуры понадобилось бы какое-то время.
Дополнительно «АТИМО» попросили сделать опрос таксопарков более частым — с загрузкой новых данных каждую минуту. Это требование проектная команда также выполнила: технически шина может работать даже быстрее.
Правда, с такой скоростью не справлялись уже базы данных таксопарков. Для одной особенно медленной базы пришлось искусственно ограничить число запросов, т. к. ежеминутные подключения она воспринимала как DDoS-атаку — и блокировала шину.
Обновление внедрили, и в «АТИМО» сразу заметили улучшение. Шина работала без сбоев, запросов в техническую поддержку практически не было. Решение получилось экономичным по потреблению памяти и при этом достаточно стабильным.
В чём ошибка
На первый взгляд всё было отлично: ESB 2.0 работала стабильно, к ней успешно подключали новые таксопарки. Примерно через месяц их было уже 15.
Проблема была в том, что архитектура ESB осталась неправильной: один сервис последовательно опрашивал все 15 баз данных. При этом система «АТИМО» продолжала расти, и было понятно, что рано или поздно шина снова начнёт сбоить.
Ошибка этой версии заключалась в том, что проектная команда сфокусировалась на экономии ресурсов сервера и сокращении времени разработки. Ключевая архитектурная проблема ESB 1.0 сохранилась и в ESB 2.0, поэтому шину пришлось снова дорабатывать.
Как надо было сделать
Чтобы ESB была действительно отказоустойчивой, нужно реализовать правильную архитектуру. Лучшее решение в подобной ситуации — обсудить с заказчиком реальные сроки разработки. Полное обновление требует времени, но при этом позволяет получить масштабируемую и надёжную шину данных.
Команда KT.Team уже знала, что нужно изменить, поэтому не стала ждать запроса от «АТИМО» или сбоя ESB и переделала шину по своей инициативе.
Финальная ESB: надёжная, стабильная и быстрая
Что сделали
В ESB 3.0 мы реализовали архитектуру, от которой отказались в предыдущей версии, — с отдельными сервисами для каждой базы данных. Все сервисы работают одинаково:
- подключаются к базе данных таксопарка;
- скачивают из неё данные;
- приводят их к формату, который использует система «АТИМО» (для этого настроили правила маппинга);
- записывают новые данные в хранилище;
- удаляют неактуальные данные.
Чтобы сервисы не тратили много ресурсов сервера, их сделали максимально простыми: убрали все лишние и ресурсоёмкие шаги, такие как логирование исключений. Вместо этого данные в хранилище перезаписываются при каждом успешном подключении к базе таксопарка. Опрос одного таксопарка теперь требует около 300 Мб памяти (вместо 4 Гб на старте проекта).
Финальную версию сервисной шины выкатили незадолго до наступления 2023 года. После этого KT.Team до конца января не получила ни одного запроса на оказание технической поддержки. А первый вопрос от «АТИМО» вообще не касался надёжности сервисной шины.
Дело в том, что в ESB 3.0 есть полезная фича: новую точку подключения для таксопарка можно создать простым клонированием из любой существующей. Затем нужно задать несколько настроек, и ESB сможет получать нужные данные. Это решение сделало шину масштабируемой — «АТИМО» не нужно обращаться в техподдержку, чтобы добавить таксопарк.
Команда KT.Team составила пошаговую инструкцию, чтобы сделать процесс понятнее. Именно с ней был связан первый вопрос от «АТИМО» — описание одного из шагов оказалось не совсем понятным. На вопрос ответили, текст подправили, и теперь добавление нового таксопарка занимает всего пару часов вместо нескольких дней, как было раньше.
Что получилось в итоге
«АТИМО» успешно интегрирует новые таксопарки с ESB 3.0 без помощи KT.Team. За первые 3,5 месяца 2023 года команда стартапа добавила 10 новых интеграций самостоятельно, используя документацию. Сейчас в системе уже 20 таксопарков, а баз данных, из которых шина забирает информацию о водителях и машинах, вдвое больше.
Ограниченные ресурсы сервера «АТИМО» используются экономно: на один запрос уходит всего 300 Мб памяти вместо 4 Гб при прямом подключении. Сократить потребление удалось благодаря очень простой схеме сервиса, который опрашивает базу данных таксопарка.
В чате техподдержки тихо: шина выполняет свои функции, а редкие вопросы связаны с небольшими локальными сбоями на стороне отдельных баз данных. Чаще всего вопрос решается сам собой: таксопарк налаживает работу на своей стороне, и система «АТИМО» получает обновлённые данные.
В этой истории команда KT.Team приобрела ценный опыт и отработала процесс внедрения ESB. Важно сразу учесть и будущий рост, и возможные точки отказа в системе, проводя внедрение правильно. Поэтому лучше всего подобную шину реализовать через отдельные сервисы для каждого подключения, даже если пока их всего два.
